_run_subprocess calls process.communicate() with no timeout when probing candidate Python interpreters. On Windows CI runners, this subprocess can hang indefinitely — typically caused by Windows Store Python stubs, antivirus file locks, or pipe I/O race conditions between short-lived child processes and the parent's reader threads. 🪟 Analysis of the last 30 days of tox CI revealed 18 flaky timeout failures across 9 different tests, almost exclusively on windows-2025 runners (with 2 on macos-15).

The failures fall into two patterns that share the same deadlock chain in tox's common.py. Pattern A (discovery): the tox-driver thread hangs in _run_subprocess → process.communicate() while probing interpreters. Pattern B (install/provision): a package install or provision subprocess hangs. In both cases, thread.join() blocks the main thread so KeyboardInterrupt can never be delivered, as_completed() blocks the interrupt thread so it can't check the interrupt event, and executor.shutdown(wait=True) prevents cleanup — creating an unbreakable deadlock.

The fix adds a 5-second timeout to process.communicate(). ⏱️ The probed subprocess only reads sys attributes and prints JSON — a healthy interpreter completes this in milliseconds, so 5 seconds is generous. On timeout the hung process is killed and treated as a failed probe, allowing discovery to skip it and continue to the next candidate. This fits naturally into the existing error-handling flow since non-zero exit codes already produce a RuntimeError that callers handle gracefully. A companion PR in tox addresses the deadlock chain in common.py to handle Pattern B and make the execution engine interruptible.

Also fixes a pre-existing ty type-check failure where ty 0.0.17 with --python-version 3.8 completely misresolves pytest.skip (a _WithException-wrapped function) as a bound method with no parameters — replaced with raise pytest.skip.Exception(msg) which bypasses the broken wrapper.